File backup to combat ransomware

ABSTRACT

Operating system events are monitored and a file change request of a process is detected. If the process is suspicious, then the file to be changed is backed up and then the process is allowed to change the file as requested. If it is later determined that the process is ransomware, the process is blocked and further file backups are halted. The original file is recovered and the encrypted file is discarded. If it is later determined that the process is not malicious, then further file backups are halted. Any backup files are discarded. Ransomware may be detected by comparing a file extension of the process with file extensions of any files requested to be changed, by comparing file extensions of any files requested to be changed, or by an analysis of behavior of the process itself.

FIELD OF THE INVENTION

The present invention relates generally to antivirus software. Morespecifically, the present invention relates to detection and preventionof malicious software that encrypts files on a computer hard drive.

BACKGROUND OF THE INVENTION

Malicious software (such as computer viruses, worms, etc., known as“malware”) is often a problem for computer users and the antivirusservice providers constantly deal with new threats. One type of newthreat that is currently causing problems for users is termedransomware.

As its name implies, ransomware is a class of malware which restrictsaccess to the computer system that it infects, and often requires that aransom be paid to the creator of the malware in order for therestriction to be removed. Some forms of ransomware encrypt files on thecomputer's hard drive, while others may simply lock the computer; in anycase, the ransomware displays messages intended to convince the user topay the ransom. Apparently, ransomware is a new way for cybercriminalsto defraud computer users after the decline of fake antivirus software.According to antivirus service providers, ransomware is one of the topsecurity threat predictions for 2013 and the number of instances ofransomware continues to increase dramatically since 2011.

Basically, ransomware can be classified into two categories: encryptingransomware and non-encrypting ransomware. Encrypting ransomware encryptspersonal files on the hard drive. More sophisticated ransomware malwaremay encrypt the victim's data with a random symmetric key and a fixedpublic key. By design, the malware author is the only one who knows thenecessary symmetric key or private decryption key. The malware author isthen in a position to demand a ransom, and, in some cases, even if thevictim pays money to the cybercriminal the cybercriminal may not decryptthe hard drive. It can be a disaster for a computer user to lose years'worth of data, pictures and files. The situation can be much worse foran enterprise if the malware encrypts all of the data that employeesneed to access on a corporate network.

The most notorious ransomware to date is “GpCode.” For example, themalware “Trojan-Ransom.Win32.Gpcode.bk” (a Kaspersky detection name)encrypts all user files having dozens of extensions. The malwareencrypts documents, pictures, archives, database source files, sourcecode and HTML pages. All valuable data on a computer will be unusable.The latest Gpcode variant generates an AES 256-bit key and uses thecriminal's public RSA 1024-bit key to encrypt the AES key. Without theprivate key, it is nearly impossible to decrypt the encrypted files.

Current technology used to combat ransomware involves techniques usedafter the encryption has occurred. For example, for ransomware that usesa custom encryption routine, one antivirus service provider providesspecial software tools to decrypt the files after hacking into theencryption routine in the virus body. In addition, if the malwarecreates a new encrypted file in a different location and then deletesthe original file, it is sometimes possible to recover the original filewith disk recovery tools such as “PhotoRec.” Unfortunately, with theevolution of ransomware and its use of stronger and strongercryptography, it can be impossible to decrypt the files after infection.

Thus, most all of the current techniques rely upon recovering from theransomware infection. But, the user's data cannot be recovered if thecryptography is strong. Relying upon periodic backup of files is oftennot practical because not all users will perform this task. And, in somecases, users backup their files on the same hard disk or backup files ona separate hard disk which may also be affected by the malware.Accordingly, new techniques are desired that can effectively combatransomware.

SUMMARY OF THE INVENTION

To achieve the foregoing, and in accordance with the purpose of thepresent invention, a technique is disclosed that not only detects thatransomware is in operation, but also backs up files before theransomware has an opportunity to encrypt the files and removes theransomware.

The disclosed technique protects a user and his or her computer files inreal time and can prevent encryption of large number of files. Even iffiles are encrypted by the ransomware, the user's data can be recoveredvia the backups that occur in real time. Moreover, using behavior-baseddetection, ransomware can be blocked soon after it begins to encrypt acertain number of files. Thus, a backup engine does not need to backup agreat number files which produces a limited impact on systemperformance.

In a first embodiment, system events are monitored and a file changeevent of a process is detected. If the process is determined to besuspicious, then the file to be changed is backed up and then the fileis allowed to be changed by the process. When it is determined that theprocess is ransomware, the process is blocked and further file backupsare halted. The original file is recovered and the encrypted file isdiscarded.

In a second embodiment, a system monitor detects that a particularprocess is requesting that a computer file be changed. If it isdetermined that the process is suspicious, then the computer file isbacked up to a location other than the hard disk before the file isallowed to be changed as requested. When it is concluded that theprocess is not malicious, then any file backups associated with theprocess are halted. The backed up file may be discarded.

In a third embodiment, a file is backed up when it is determined that asuspicious process requests to change the file. It may be concluded thatthe suspicious process is ransomware by comparing a file extension ofthe process with file extensions of any files requested to be changed,by comparing file extensions of any files requested to be changed, or byan analysis of behavior of the process itself.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention, together with further advantages thereof, may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings in which:

FIG. 1 is a system architecture of software modules and databases on acomputer used to combat ransomware.

FIG. 2 is a flow diagram describing a specific embodiment of howransomware is detected and blocked.

FIGS. 3A and 3B illustrate a computer system suitable for implementingembodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Rather than addressing the problem created by ransomware after itoccurs, i.e., attempting to decrypt encrypted files, the presentinvention detects and blocks ransomware in real time. In addition, it isrealized that real-time monitoring of system processes is fast enough todetect ransomware before it encrypts a file, thus allowing the file tobe backed up before the ransomware encrypts the file. Cleverly, thepresent invention may allow a certain number of files to be encrypted;because those files will be backed up before encryption by theransomware, it is of no matter that they will be encrypted. Once aninfection of ransomware is confirmed, the malware may be removed.

System Architecture

FIG. 1 is a system architecture 10 of software modules and databases ona computer used to combat ransomware. The computer may be any suitablecomputing device such as a desktop computer, laptop computer, fileserver, mainframe computer, tablet computer, or even a mobile telephone.As is known in the art, typically an operating system of the computerincludes a kernel mode 102 (which includes processes managed by theoperating system), and a user mode 104 (which includes user processes).

System 10 includes a system monitor driver 110 which resides in thekernel. This software module hooks relevant system events such as: fileevents (e.g., open file, write file, delete file, create file, renamefile); registry events (e.g., create registry key, add registry value,delete registry key, delete registry value); process and thread events(e.g., create new process, create new thread, terminate process,terminate thread); and network events (e.g., the IP address of a remoteserver, the port used to connect, the URL to access, etc.). Any of theuser mode modules will be able to receive events from this driver.

The abnormal file change correlation engine 120 is a software modulewith the responsibility to detect any malicious or file encryptionactivity by correlating events received from system monitor driver 110.The correlation engine 120 also determines whether to back up a filebefore the file is changed (e.g., written to or deleted). For example,when a suspicious process launches, engine 120 may notify backup engine130 to back up files that the process will change. If engine 120confirms that the process is ransomware (e.g., by correlating eventsfrom that process), it may notify driver 110 to block this process andcall clean engine 180 to remove the process. If the engine 120 confirmsthat the process is harmless, it may notify backup engine 132 to ceasebacking up files. The engine 120 may use rules to apply to receivedevents, and these rules may be deployed as a pattern file and thispattern file is updatable. When the correlation engine starts to run, itloads the rules of the pattern into memory of the computer.

Backup engine 130 is a software module for performing file backup.Because of the correlation performed by correlation engine 120, backupengine 130 only needs to backup files about to be changed by asuspicious process. After the process has been analyzed by correlationengine 120, there typically will be no further need for file backup. Ifthe process is judged to be normal, the correlation engine can ignorelater events and previously made backups can be removed. If the processis judged to be malicious, the process will be blocked (and thus nofurther need to backup files that might be changed). Thus, the number ofbackup requests is limited and the impact on system performance isrelatively minor. Any data that was actually encrypted by ransomware maybe recovered from the backed up files. In fact, in order to betterprotect user's data, backup engine 130 may even trigger creation of asystem restore point.

System restore database 140 is a database that may be used by the SystemRestore system utility in the Microsoft operating system to create arestore point for later recovery of files. As is known in the art, arestore point maybe created at any point in time for any number ofcomputer files, and the state of these files at this time may berecovered at a future time. Other utilities in other operating systemsmay also be used to create the equivalent of a restore point and mayalso utilize database 140. Database 150 is any suitable database used tobackup files on the computer. In various embodiments, database 150exists on the hard disk of the computer, is a database existing on anexternal hard drive, is a database on an external solid-state drive suchas a USB drive or other solid-state medium, is a remote databaseaccessed over the Internet, etc. In one embodiment, the backup databasemay be located on the same hard disk where the computer files arelocated. The database is protected by the kernel module and any accessnot from an approved process is forbidden in order to avoid infectionfrom ransomware or other malware.

As mentioned, clean engine 180 is any suitable software module typicallyprovided by an antivirus service provider which is able to removemalware from a computer usually by deleting the actual malware files anddeleting malware specific registry entries and other components droppedor downloaded by the malware. Clean engine 180 is presented with thename of a malware file (such as a ransomware file name“C:\Users\kenny\AppData\Roaming\a123.exe”) and the clean engine thenproceeds to remove this malware and its effects from the computer. Oneexample of a clean engine is Trend Micro's damage cleanup engine. It isable to delete the ransomware file and all related items in a system.The clean engine also is able to access the backup database in order torestore all of the files encrypted by the ransomware, or, the cleanengine notifies the backup engine to do this.

Local white list 160 is a white list that includes file identifiers suchas file names, unique identifiers, CRC values, MD5 values, etc., thatidentify files or processes that are known to be benign. White list 160may be used by the correlation engine to avoid triggering an alert orfile backup if the file or process in question causing an event is knownto be benign. Similarly, cloud service 170 provides the reputation of aparticular file (when provided with information such as the file name,CRC, MD5, or other file identifier) or the reputation of a particularWeb site to the correlation engine 120 executing upon the user computer.

Flow Diagram

In general, the workflow of the present invention may be described withreference to FIG. 1. Relevant events are hooked within the systemmonitor driver 110 (i.e., events that indicate suspicious activity,events that indicate that a particular process may be malware, etc.),and these events are passed 191 to the correlation engine 120 in realtime. If the correlation engine determines after a review of events thata potential file change has been initiated by a suspicious process, thenthe correlation engine sends a trigger signal 192 to backup engine 130.Backup engine 130 then backs up 193 the file into either database 150 orinto a system restore point 140. The backed up file may be used torecover from any damage caused by ransomware or other malware. Afterreviewing the file activities of a particular suspicious process, if thecorrelation engine confirms that the process is ransomware, then a blocksignal 194 is sent to driver 110 in order to block the process. Inaddition, engine 120 will send a notify signal 195 to clean engine 180in order to clean the ransomware from the computer.

FIG. 2 is a flow diagram describing a specific embodiment of howransomware is detected and blocked. The system monitor driver 110continuously monitors system events 204 using system hooks. Althoughdriver 110 is able to monitor all system events, in one embodiment itmay focus exclusively upon file events in order to detect when a file isabout to be changed. Monitoring all events, though, may assist thecorrelation engine in determining whether or not a particular process ismalicious. In step 208 these monitored events are sent to correlationengine 120.

Step 212 determines whether an event has occurred indicating that a userprocess is attempting to change one of the files on the hard disk (forexample, hooking of a system function indicates that a process isattempting to overwrite a file, write a new version of a file, encrypt afile, delete a file, etc.). If no file change event is currentlydetected, it is likely that ransomware is not currently executing uponthe computer and control returns to step 204 for more monitoring ofevents. On the other hand, if a file change event is detected, thencontrol moves to step 216 to determine whether or not the file inquestion should be backed up.

Step 216 determines whether the process (or thread) that has requestedthe file change event is suspicious or not. In general, determiningwhether a process (or the file that created it) is suspicious may beaccomplished using information obtained from operating system hooksinstalled in the system monitor driver 110, using information from aremote cloud service 170, or from information using a local white list160. Once all of this information is obtained concerning a particularfile or process, then heuristics such as rules may be used to make adetermination as to whether the file or process is suspicious.

As explained above, driver 110 hooks a variety of system events andprovides information on files, registries, processes, etc. For example,using kernel hooks, it is possible to determine when a file was firstcreated (dropped) on a hard drive of the computer, from where the filecame (e.g., downloaded from a particular Web site, dropped by anotherfile, copied from removable media, etc.), and how specifically the filelanded on the user's hard drive. Other events that may be hooked includewhat the file does, any suspicious registry items added, the server towhich the computer connects, the communications content with the remoteserver, etc.

A remote cloud service 170 can also provide the reputation of aparticular file as explained above. In addition, the local white list160 may also provide the reputation of a particular file to thecorrelation engine. The correlation engine continuously gathers thisinformation (as relevant events 191 are constantly being sent fromdriver 110) and may especially query a source outside of driver 110 whena particular file or process registers a file change event in theprevious step. Once gathered, rules may be used to determine whether afile or process is suspicious.

For example, the following rules (when true) tend to indicate that afile or process is suspicious: the file is dropped on the hard diskwhile the user views a particular Web site; the user opens an attachmentof an e-mail message to access the file; the process is an injectedthread; the file has no digital signature and its file reputation ispoor; the process added an auto start registry value; the processconnects to a suspicious remote network port; etc.

If the process is suspicious, then control moves to step 220. On theother hand, if the process is not suspicious than the system continuesto monitor system events as usual and the file is not backed up becauseit is likely a normal file change event. Of course, step 216 may beperformed before step 212, or both steps may be performed more or lessat the same time.

Step 220 backs up any file or files that are about to be changed by theevent detected in step 212. Bear in mind that the file change event thatwas hooked by driver 110 and detected in step 212 has not yet changedthe file in question. The hook function that detected the file changeevent allows steps 216 and 220 to occur before control returns to thesystem function that is attempting to change the file. In other words,the file change event is detected, a determination is made that theprocess is suspicious, and the file is backed up before the requestingprocess is allowed to change the file. Once the correlation engine makesthe determination to backup the file, a trigger signal is sent to thebackup engine which then saves the file in question from the hard diskto either database 150 or to database 140. For example, since the filehas not been changed, the backup engine makes a copy of the file andsaves it in a special backup folder. Then the engine adds a new recordin the backup database. The record includes: the file path of theprocess, the path of the file to be modified, the backup file name andpath, and other information. The database record is then later used toretrieve the backed up file. To reduce the disk usage, the backed upfile may be compressed. It can be expanded later when the original fileis needed.

After the backup has been performed, control is returned to the systemprocess to allow the file to be modified as requested. This particularimplementation may use the callback mechanism in the operating system.For example, the user mode module registers a callback function with thehook module, and all of the correlation and backup work is done in thecallback routine. Once this work is finished, control is returned to thehook module from the routine which then returns control to the systemprocess. Once the file has been backed up, then the process is allowedto complete its originally requested file change event.

Steps 204-220 may be performed continuously for any number of filechange events and for any number of files that need to be backed upbefore being changed. The correlation engine is also continuouslygathering information in order to make a conclusive determination as towhether the process is malicious. This conclusion may occur before anyfile change event, or may occur after a file or files have been backedup. Preferably, a conclusion is reached as quickly as possible so that aminimum number of files are backed up. Advantageously, once adetermination is made one way or the other, then it is not necessary tocontinue backing up files that are about to be changed by the process inquestion.

Accordingly, step 224 determines whether the process is malware, or morespecifically, whether the process is ransomware. In general, making adetermination that the process is malware may be performed using any ofthe rules described above in step 216. For example, it may be concludedthat a particular process is malicious if it satisfies a certain numberof rules.

More specifically, rules specific to detecting ransomware may be used toconclude that the process is ransomware. For example, it is realizedthat the typical behavior model of ransomware that encrypts files on acomputer hard drive is that a process (or thread) A attempts to write ordelete files B, C, D. Thus, three particular categories of rules areused. The first category deals with attributes of the process A, andexamples of rules in this category are: process A has been determined tobe malicious. Examples of rules in the second category deal with therelationship between process A and files B, C, D and include rules suchas: process A is not related to software identified by extensions offiles B, C, D. In other words, if files B, C, D all have the “.doc”extension (meaning that they are associated with the applicationMicrosoft Word), and process A is not a process of Microsoft Word (orany other text editor), a conclusion may be reached that process A islikely to be ransomware. The third category deals with the relationshipbetween files B, C, D and examples of rules include: the affected filesto a certain extent have different extensions; and the affected filesreside in different folders. In other words, the extension of file B is“.doc”, the extension of the file C is “.xls”, and the extension of fileD is “.jpeg”; there is no legitimate software that can function withthese three different file extensions.

An algorithm is used that provides a weighted value for each rule and ifa certain number of rules are true and a threshold value is reached,then a determination is made that the process is ransomware. If so, thencontrol moves to step 232. If the process is not malicious, then controlmoves to step 228. For example, a calculation may be as follows.Score=1*(count of requested modified files)+2*(count of modified fileextensions)+3*(count of modified files in different folders). If theprocess is suspicious and the requested modifications occur within 3seconds, and the score is over 20, then the correlation engine willdetermine that the process is ransomware.

In step 228 file backups are halted (even if file change events aredetected and events indicate that the process might be suspicious)because a determination has been reached that the process is notmalicious. Backups are halted by setting a flag in the correlationengine indicating that backups are not necessary for a particularprocess or thread, by similarly alerting the backup engine, or byignoring the file change event from the particular process or thread andperforming no more correlation for that process or thread. Once backupsare halted for the particular process then events continue to bemonitored as described above.

In step 232 the process in question is blocked (because it is malwareor, more specifically is ransomware) by sending a signal from thecorrelation engine to the system monitor driver. Driver 110 blocks theparticular process or thread by making any of its file access requestfail.

In step 236 the correlation engine also sends a notification to theclean engine 180 to remove the malicious process and all of itsartifacts from the computer. The information that the engine passes tothe clean engine is the file path of the malicious process in order toallow the cleaning to occur.

In step 240 the clean engine then directs the backup engine to recoverany files that had recently been backed up before they were changed bythe malicious process. For example, the clean engine passes the filepath of the ransomware to the backup engine. The backup engine thenqueries the backup database with this path to get the list of all filesthat have been backed up before the ransomware changed them. Then, thebackup engine uses the backed up files to replace the encrypted filesone-by-one. The encrypted files may be moved to a special folder ordeleted.

In addition, since the original files are recovered, the encrypted filesare then made inaccessible (or otherwise unusable) to a computer user orother software application by performing steps such as deleting theencrypted files, changing the names of the encrypted files, moving theencrypted files to an inaccessible location, etc.

In this fashion, the original files are restored to a state beforeencryption by the ransomware and any file that has been changed orencrypted by the ransomware is removed from the computer or is madeinaccessible so that a computer user or software application will notinadvertently access the changed file.

Computer System Embodiment

FIGS. 3A and 3B illustrate a computer system 900 suitable forimplementing embodiments of the present invention. FIG. 3A shows onepossible physical form of the computer system. Of course, the computersystem may have many physical forms including an integrated circuit, aprinted circuit board, a small handheld device (such as a mobiletelephone or PDA), a personal computer or a super computer. Computersystem 900 includes a monitor 902, a display 904, a housing 906, a diskdrive 908, a keyboard 910 and a mouse 912. Disk 914 is acomputer-readable medium used to transfer data to and from computersystem 900.

FIG. 3B is an example of a block diagram for computer system 900.Attached to system bus 920 are a wide variety of subsystems.Processor(s) 922 (also referred to as central processing units, or CPUs)are coupled to storage devices including memory 924. Memory 924 includesrandom access memory (RAM) and read-only memory (ROM). As is well knownin the art, ROM acts to transfer data and instructions uni-directionallyto the CPU and RAM is used typically to transfer data and instructionsin a bi-directional manner. Both of these types of memories may includeany suitable of the computer-readable media described below. A fixeddisk 926 is also coupled bi-directionally to CPU 922; it providesadditional data storage capacity and may also include any of thecomputer-readable media described below. Fixed disk 926 may be used tostore programs, data and the like and is typically a secondary storagemedium (such as a hard disk) that is slower than primary storage. Itwill be appreciated that the information retained within fixed disk 926,may, in appropriate cases, be incorporated in standard fashion asvirtual memory in memory 924. Removable disk 914 may take the form ofany of the computer-readable media described below.

CPU 922 is also coupled to a variety of input/output devices such asdisplay 904, keyboard 910, mouse 912 and speakers 930. In general, aninput/output device may be any of: video displays, track balls, mice,keyboards, microphones, touch-sensitive displays, transducer cardreaders, magnetic or paper tape readers, tablets, styluses, voice orhandwriting recognizers, biometrics readers, or other computers. CPU 922optionally may be coupled to another computer or telecommunicationsnetwork using network interface 940. With such a network interface, itis contemplated that the CPU might receive information from the network,or might output information to the network in the course of performingthe above-described method steps. Furthermore, method embodiments of thepresent invention may execute solely upon CPU 922 or may execute over anetwork such as the Internet in conjunction with a remote CPU thatshares a portion of the processing.

In addition, embodiments of the present invention further relate tocomputer storage products with a computer-readable medium that havecomputer code thereon for performing various computer-implementedoperations. The media and computer code may be those specially designedand constructed for the purposes of the present invention, or they maybe of the kind well known and available to those having skill in thecomputer software arts. Examples of computer-readable media include, butare not limited to: magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROMs and holographic devices;magneto-optical media such as floptical disks; and hardware devices thatare specially configured to store and execute program code, such asapplication-specific integrated circuits (ASICs), programmable logicdevices (PLDs) and ROM and RAM devices. Examples of computer codeinclude machine code, such as produced by a compiler, and filescontaining higher-level code that are executed by a computer using aninterpreter.

Although the foregoing invention has been described in some detail forpurposes of clarity of understanding, it will be apparent that certainchanges and modifications may be practiced within the scope of theappended claims. Therefore, the described embodiments should be taken asillustrative and not restrictive, and the invention should not belimited to the details given herein but should be defined by thefollowing claims and their full scope of equivalents.

We claim:
 1. A method of backing up a computer file, said methodcomprising: continuously monitoring system events within an operatingsystem of a computer; detecting that a process executing on saidcomputer is requesting that said computer file in persistent storage ofsaid computer be changed; determining that said process is suspected ofbeing malicious before said computer file is changed; backing up saidcomputer file to a storage location different from a current location ofsaid computer file in said persistent storage, said backing up occurringbefore said computer file is changed and only occurring when saidprocess is suspected of being malicious; and allowing said suspiciousprocess to change said computer file as requested; determining that saidsuspicious process is not malicious by comparing a file extension ofsaid computer file with said suspicious process; and halting any furtherfile backups for computer files associated with said suspicious process.2. The method as recited in claim 1 wherein said suspicious process isransomware, and wherein said suspicious process is allowed to encryptsaid computer file.
 3. The method as recited in claim 1 wherein saidsuspicious process executes in user mode of said computer.
 4. The methodas recited in claim 1 further comprising: allowing said suspiciousprocess to encrypt said computer file; determining that said suspiciousprocess is ransomware; and terminating execution of said suspiciousprocess once said determination of ransomware is made.
 5. The method asrecited in claim 1 further comprising: recovering said backed upcomputer file from said storage location; and rendering inaccessiblesaid changed computer file.
 6. The method as recited in claim 1 whereinsaid detecting includes intercepting an operating system call to changesaid computer file, said method further comprising: returning control tosaid operating system call after said backing up in order to permit saidallowing to occur.
 7. The method as recited in claim 1 furthercomprising: determining that said process is suspected of beingmalicious in real time after said detecting.
 8. The method as recited inclaim 1 further comprising: determining that said suspicious process isnot malicious by comparing resident folders of other computer files thatsaid suspicious process is requesting be changed.
 9. The method asrecited in claim 8 wherein each of said comparing steps produces aweighted value, said method further comprising: determining that a scoreof said weighted values is not over a threshold.
 10. A method of backingup a computer file, said method comprising: continuously monitoringsystem events within an operating system of a computer; detecting that aprocess executing on said computer is requesting that said computer filein persistent storage of said computer be changed; determining that saidprocess is suspected of being malicious before said computer file ischanged; backing up said computer file to a storage location differentfrom a current location of said computer file in said persistentstorage, said backing up occurring before said computer file is changedand only occurring when said process is suspected of being malicious;allowing said suspicious process to change said computer file asrequested; determining that said suspicious process is not malicious bycomparing a file extension of said computer file with said suspiciousprocess; and halting any further file backups for computer filesassociated with said suspicious process.
 11. The method as recited inclaim 10 wherein said suspicious process executes in user mode of saidcomputer.
 12. The method as recited in claim 10 further comprising:determining that said suspicious process is not malicious using a localwhite list on said computer.
 13. The method as recited in claim 10further comprising: determining that said suspicious process is notmalicious using a remote cloud service.
 14. The method as recited inclaim 10 wherein said detecting includes intercepting an operatingsystem call to change said computer file, said method furthercomprising: returning control to said operating system call after saidbacking up in order to permit said allowing to occur.
 15. The method asrecited in claim 10 further comprising: determining that said process issuspected of being malicious in real time after said detecting.
 16. Themethod as recited in claim 10 further comprising: determining that saidsuspicious process is not malicious by comparing resident folders ofother computer files that said suspicious process is requesting bechanged.
 17. The method as recited in claim 16 wherein each of saidcomparing steps produces a weighted value, said method furthercomprising: determining that a score of said weighted values is not overa threshold.
 18. A method of backing up a computer file, said methodcomprising: detecting that a process executing on said computer isrequesting that said computer file in persistent storage of saidcomputer be changed; determining that said process is suspected of beingmalicious before said computer file is changed; backing up said computerfile to a storage location different from a current location of saidcomputer file in said persistent storage, said backing up occurringbefore said computer file is changed and only occurring when saidprocess is suspected of being malicious; allowing said suspiciousprocess to encrypt said computer file as requested; determining thatsaid suspicious process is not malicious by comparing a file extensionof said computer file with said suspicious process; and halting anyfurther file backups for computer files associated with said suspiciousprocess.
 19. The method as recited in claim 18 further comprising:determining that suspicious process is ransomware by comparing a fileextension of said suspicious process with a file extension of saidcomputer file.
 20. The method as recited in claim 18 wherein saidsuspicious process executes in user mode of said computer.
 21. Themethod as recited in claim 18 further comprising: determining thatsuspicious process is ransomware by comparing a file extension of saidcomputer file with a file extension of a second computer file that saidsuspicious process is requesting be changed.
 22. The method as recitedin claim 18 further comprising: recovering said backed up computer filefrom said storage location; and rendering inaccessible said changedcomputer file.
 23. The method as recited in claim 18 wherein saiddetecting includes intercepting an operating system call to change saidcomputer file, said method further comprising: returning control to saidoperating system call after said backing up in order to permit saidallowing to occur.
 24. The method as recited in claim 18 furthercomprising: determining that said process is suspected of beingmalicious in real time after said detecting.
 25. The method as recitedin claim 18 further comprising: determining that said suspicious processis not malicious by comparing resident folders of other computer filesthat said suspicious process is requesting be changed.
 26. The method asrecited in claim 25 wherein each of said comparing steps produces aweighted value, said method further comprising: determining that a scoreof said weighted values is not over a threshold.